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Three  Complementary  Constellations 


CMMI-DEV  provides 
guidance  for 
measuring,  monitoring, 
and  managing 
development  processes 


CM  Ml -SVC  provides 
guidance  for  those 
providing  services 
within  organizations  and 
to  external  customers 


CMMI-ACQ  provides 
guidance  to  enable 
informed  and  decisive 
acquisition  leadership 
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Schedule  for  CMMI  VI  .3  Models 


Preparation  Change  Packages  (CPs)  QA 

Jan -May  2009  June  2009  -  Feb  2010  July  -  Nov  1 , 2010 


CCB  Review  of  CPs  CCB  Review  of  Redlines 
July  2010  -  Feb  2010  Mar -April  2010 


CCB  Review  of  VI  .3  Draft 
July  2010 

□ 


Redlines 

Aug  2009  -  April  2010 


VI  .3  Updates 
May  -  July  2010 


Piloting  P-Drafts* 

Nov,  Feb,  March,  and  June 

D  DO  D 


Entire  Project  =  Jan  2009  to  November  1 , 201 0 


*  Piloting  will  include  candidate  solutions  for  appraising  multiple 
constellations  as  well  as  a  training  approach  for  CMMI. 
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Schedule  for  CMMI  VI. 3  Appraisal  Products 


Jan  ‘09 -July  ‘09 


CR  Analysis 

Aug  ‘09  -  Jan‘10 

Write  CPs 

Feb  ‘10  -  Jun‘10 

Write  Redlines 

J 

Dec  ’09-Feb‘IO 


CCB  CPs 


Apr‘  10- Jul‘10 
CCB  Redlines 

wM  IHH0 


Jan  ‘10- Jun  ‘10 
Piloting  Period 


Sep-Oct‘10 


Aug  Review 
&  Revise 


Nov 


QA2 
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CMMI  VI  .3  Criteria 


Correct  identified  model,  training  material,  or  appraisal  method  defects  or  provide  enhancements. 
Incorporate  amplifications  and  clarifications  as  needed. 

Accommodate  potential  additions  to  model  coverage  (e.g.,  safety,  security,  life  cycle)  only  by  specific 
direction  of  the  CMMI  Steering  Group. 

Decrease  overall  model  size  in  vl  .3  if  possible;  increases,  if  any,  must  not  be  greater  than  absolutely 
necessary. 

Model  and  method  changes  should  avoid  adversely  impacting  the  legacy  investment  of  adopting 
companies  and  organizations. 

Changes  to  model  architecture  will  only  be  incorporated  with  specific  CMMI  Steering  Group  authorization. 
Changes  may  only  be  initiated  by  Change  Requests  or  the  CMMI  Steering  Group. 

Editorial  changes  to  training  may  be  released  in  advance  of  vl  .3. 

Changes  must  not  cause  retraining  of  the  nearly  1 00,000  (as  of  Dec  2008)  personnel  already  trained  in 
CMMI.  Upgrade  training  may  be  needed,  especially  for  Instructors,  Lead  Appraisers,  and  appraisal  team 
members. 
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CMMI  Product  Suite,  Version  1.3 


Version  1 .3  will  focus  on  but  not  be  limited  to  the  following: 

•  High  Maturity 

•  Appraisal  efficiency 

•  Consistency  across  constellations 

•  Simplify  the  generic  practices 

Version  1 .3  is  change  request  (CR)  driven.  Events  such  as  this  webinar 
presentation  are  for  information  sharing  and  dialogue. 
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Version  1 .3  Model  Updates 
All  But  High  Maturity 
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Model  Architecture 


Typical  Work  Products 

Renamed  “typical  work  product”  to  be  “example  work  product.”  In  CMMI- 
ACQ,  “typical  supplier  deliverable”  was  renamed  to  be  “example  supplier 
deliverable.” 

Amplifications 

Removed  the  “amplification”  model  component. 

IPPD/Teaming 

Removed  the  IPPD  addition  from  CMMI-DEV  and  in  its  place  added 
teaming  practices  used  in  CMMI-ACQ  and  CMMI-SVC,  which  are 
practices  that  are  not  optional. 
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PA  Categories 


CMMI-ACQ 

Renamed  the  “Acquisition”  process  area  category  to  be  “Acquisition 
Engineering.” 

Moved  AM  and  SSAD  from  the  Acquisition  PA  category  to  the  Project 
Management  PA  category. 

CMMI-DEV 

Moved  REQM  from  the  Engineering  PA  category  to  the  Project 
Management  PA  category. 
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New  Material 


Update  selected  process  areas  to  provide  interpretation  of  practices  for 
organizations  with  respect  to  the  following  topics: 

•  Agile  methods 

•  Quality  attributes  (i.e. ,  non  functional  requirements  or  “ilities”) 

•  Allocation  of  product  capabilities  to  release  increments 

•  Product  lines 

•  System  of  systems 

•  Architecture-centric  development  practices 

•  Technology  maturation 

•  Customer  satisfaction 


CM  Ml  VI  .3 

Software  Engineering  Institute  CarnegieMellon  February  23,  2010 
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Terminology 


Used  “team”  instead  of  “integrated  team”  in  most  cases  when  discussing 
teaming  practices. 

Simplified  phrases  such  as  “work  products,  measures,  and  improvement 
information”  with  simpler  expressions  such  as  the  word  “experiences.” 

Revised  the  terminology  in  engineering-related  material  from  a  strong 
emphasis  on  “functionality”  to  a  more  balanced  “behavior  (functionality  and 
quality  attributes)”  or  simply  “functionality  and  quality  attributes.” 

Clarified  whether  the  use  of  “lifecycle”  refers  to  a  project  lifecycle,  product 
lifecycle,  or  both  throughout  the  model. 

Involved  the  CMMI  Translation  Team  during  model  development  work  to 
identify  and  resolve  translations  issues. 

Replaced  the  word  “project”  with  other  terms  where  needed.  (SVC  only) 
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GGs,  GPs,  and  GP  Elaborations 


Positioned  generic  goals,  generic  practices,  and  GP  elaborations  in  one 
central  location  as  the  first  section  of  Part  2  in  all  three  models. 

Simplified  GG1  to  make  it  more  readable. 

Renamed  GP  2.6  to  “Control  Work  Products.” 

Added  “selected  work  products”  to  the  GP  2.9  statement. 

Simplified  the  GP  3.2  statement  to  replace  “collect  work  products, 
measures,  measurement  results,  and  improvement  information”  with 
“collect  process-related  experiences.” 

Eliminated  GG4  and  GG5  (proposed). 
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Front  Matter 


Clarified  that  CMMI  models  are  not  processes  or  process  descriptions. 

Removed  any  biases  favoring  maturity  levels  or  capability  levels. 

Explained  that  core  process  areas  appear  in  all  CMMI  models  and  that 
they  can  have  different  expected  and  informative  material.  For  example, 
PP  can  have  an  SP  in  ACQ  that  is  absent  in  DEV’s  PP. 

Added  information  on  selecting  the  right  CMMI  model  for  use. 
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Glossary 


Differentiated  between  definitions  and  usage  notes  for  each  glossary  entry. 

Removed  the  following  terms  from  the  glossary:  adequate,  alternative 
practice,  amplifications,  appropriate,  as  needed,  assessment,  assignable 
cause  of  process  variation,  capability  evaluation,  discipline,  functional 
configuration  audit,  integrated  product  and  process  development, 
objective,  physical  configuration  audit,  and  program. 

Revised  the  definitions  of  “quality”  and  “corrective  action”  to  be  more 
consistent  with  ISO  definitions  of  these  terms. 


Revised  the  terms  “process,”  “development,”  and  “supplier”  to  be  more 
broadly  applicable. 

Revised  the  definition  of  “supplier  agreement”  to  include  agreements 
within  an  organization. 


-  Software  Engineering  Institute  CarnegieMellon 


CMMI  VI  .3 
February  23,  2010 

©2010  Carnegie  Mellon  University 


18 


PA  Improvements  -1 


CM  -  Clarified  that  CM  can  apply  to  hardware,  equipment,  and  other 
tangible  assets. 

DAR  -  (1)  Included  more  preparation  in  the  use  of  DAR  practices  to  help 
define  the  scope  of  alternatives.  (2)  Added  communication  of  results  and 
rationale  to  stakeholders. 

IPM  -  Simplified  SP  1 .7  to  replace  “work  products,  measures,  and 
documented  experiences”  with  “process-related  experiences.” 

IRP  -  (1)  Reorganized  the  practices  in  SG2  and  SG3  to  be  more  clear  and 
usable.  (2)  Updated  the  terminology  to  describe  “solutions”  and 
“repeatable  solutions”  in  addition  to  “workarounds,”  which  are  a  subset  of 
“repeatable  solutions.”  (SVC  only) 

MA-  (1)  Distinguished  between  and  clarify  the  relationship  among 
information  needs  and  objectives,  measurement  objectives,  and 
business/project  objectives.  (2)  Added  Table  16.1  from  CMMI-ACQto 
CMMI-DEV  and  CMMI-SVC. 
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PA  Improvements  -2 


OT  -  Expanded  its  practices  applicability  to  training  development  and 
delivery  methods  such  as  self  study,  mentoring,  and  online  training. 

PI  -  (1 )  Revised  the  end  of  the  purpose  statement  from  “ensure  that  the 
product,  as  integrated,  functions  properly,  and  deliver  the  product”  to 
“ensure  that  the  product,  as  integrated,  behaves  properly  (i.e.,  possesses 
the  required  functionality  and  quality  attributes)  and  deliver  the  product.” 
(2)  Revised  the  terminology  used  from  a  strong  emphasis  on  “integration 
sequence”  to  an  emphasis  on  “integration  strategy.”  Established  a  new 
term,  “integration  strategy,  procedures,  and  criteria”  to  use  throughout  the 
process  area.  (3)  Revised  the  SP  1 .1  practice  to  be  “Establish  and 
maintain  a  product  integration  strategy.”  (4)  Described  what  an  integration 
strategy  is  and  how  it  relates  to  an  integration  sequence.  (5)  Revised  the 
SP  3.2  practice  to  replace  “product  integration  sequence”  with  “product 
integration  strategy  and  procedures.”  (DEV  only) 
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PA  Improvements  -3 


PMC  -  Clarified  that  milestone  reviews  can  include  project  start-up  and 
project  close-out. 

PPQA  -  Clarified  that  PPQA  practices  apply  to  both  project-  and 
organization-level  activities  and  work  products. 

RD/ARD  -  (1)  Added  informative  material  that  requirements  can  be 
monitored  through  development  based  on  their  criticality  to  the  customer 
or  end  user.  (2)  Revised  the  terminology  used  from  a  strong  emphasis  on 
“operational  scenarios”  to  a  more  balanced  “scenarios  (operational, 
sustainment,  and  development).”  (3)  Revised  the  SP  3.1  statement  to 
replace  “associated  scenarios”  with  “associated  operational  scenarios.” 

REQM  -  Changed  the  focus  of  SP  1 .5  so  that  it  now  reads,  “Ensure  that 
project  plans  and  work  products  remain  aligned  with  the  requirements.” 
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PA  Improvements  -4 


SAM  -  (1 )  Clarified  the  scope  of  SAM  practices’  applicability.  (2)  Demoted 
the  SPs  “Evaluate  Selected  Supplier  Work  Products”  and  “Monitor 
Selected  Supplier  Processes”  to  be  subpractices  of  the  practice  “Accept 
the  Acquired  Product.”  (3)  Added  the  concept  “products  and  processes  of 
significant  value  to  the  project”  to  help  determine  what  to  monitor.  (4) 
Revised  the  practice  “Ensure  Transition  of  Products”  to  allow  its 
applicability  to  times  when  the  product  or  service  is  delivered  directly  to  the 
customer  or  end  user  from  the  supplier.  (SVC  and  DEV  only) 

SCON  -  Revised  the  practice  title  and  statement  of  SP  3.3  to  clarify  that 
verification  and  validation  apply  to  the  service  continuity  plan.  (SVC  only) 

SSAD  -  Added  informative  material  about  using  preferred  suppliers.  (ACQ 
only) 
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Version  1 .3  Model  Updates 
High  Maturity 
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High  Maturity  Issues 


Terminology  Confusion 

Requirements  implied  versus  explicit 

Explanations  not  central  or  consistent 

Model/  Audit  Criteria/  Presentations  (Healthy  Ingredients)/  UCHMP 

Perceptions 

Customers  -  ML  5  is  expensive  -  no  better  than  3 
Industry  -  ML  5  is  NOT  RIGHT  for  every  business 

High  Maturity  in  ALL  constellations 

Examples  are  focused  on  Development 
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Terminology:  Common  Cause 


Problem 

Change  requests  indicate  that  SPC  concepts,  and  “Common  Cause”  in 
particular,  are  over-emphasized  and  applied  inappropriately  in  the  model. 

Resolution 

Differentiate  ML  4&5  in  a  more  robust  way  -  without  relying  on  SPC  concepts  as 
THE  central  theme. 

Balance  the  treatment  of  Assignable/Common  Cause  in  Quantitative  Project 
Management  process  area  to  allow  a  greater  variety  of  quantitative  techniques 
to  be  recognized. 

Revise  glossary  entries  and  other  related  terminology  throughout  the  model  to 
avoid  narrowly  focusing  on  ‘Common  Cause’  as  a  defining  concept  of  high 
maturity. 
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Terminology: 

Process  Models  and  Process  Modeling 


Problem 

The  definition  of  the  term  process  performance  model  (PPM)  is  not  understood 

The  way  in  which  process  performance  models  are  established,  including  whether  they 
established  only  by  the  organization,  is  not  understood 

The  use  of  process  performance  models  for  process  and  project  management,  and 
process  improvement  is  not  understood 

Resolution 

Revise  the  glossary  definition  of  PPM  to  clearly  state  the  required  characteristics  based  on 
selected  parts  of  the  High  Maturity  redlines  and  “healthy  ingredients” 

For  establishing  PPMs:  (1)  Add  informative  material  to  QPM  and  OPP  stating  that  PPMs 
and  PPBs  can  be  created  by  the  organization,  projects  or  support  groups.  (2)  Revise  the 
informative  material  to  show  the  use  of  data  from  stabilized  subprocesses  is  desirable,  but 
not  required,  not  all  parameters  in  a  PPM  must  be  related  to  characteristics  of  a  sub¬ 
process 

Add  informative  material  to  QPM,  CAR,  and  OID  to  describe  the  use  of  PPMs 


UlF*  Software  Engineering  Institute  CarnegieMellon 


CMMI  VI  .3 
February  23,  2010 

©2010  Carnegie  Mellon  University 


26 


Terminology:  Business  Objectives 


Problem 

The  importance  of  using  business  objectives  to  drive  High  Maturity  activities  at 
both  an  organization  and  project  level  is  not  understood. 

The  relationship  between  organizational  quality  and  process  performance 
objectives  and  project  quality  and  process  performance  objectives  is  not  well 
understood. 

Resolution 

Add  minor  informative  material  to  OPP  and  QPM  to  clarify  proper  use  of 
business  objectives,  including  updated  examples. 


Software  Engineering  Institute  CarnegieMellon 


CMMI  VI  .3 

February  23,  2010 

©2010  Carnegie  Mellon  University 


27 


Terminology:  Subprocesses 


Problem 

The  term  subprocesses  is  not  well  understood. 

There  is  confusion  about  relationship  between  subprocesses  and  baselines  and 
models. 

The  selection  and  use  of  subprocesses  is  not  well  understood. 

Resolution 

Add  minor  informative  material  to  OPP  and  QPM  to  clarify  use  of  subprocesses, 
including  updated  examples. 
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Improve  Clarity  of  High  Maturity  Practices 


Problem  statement: 

HM  practices  are  currently  unclear,  leading  to  a  variety  of  interpretations. 
The  objective  in  a  nutshell: 

All  CMMI  users  have  a  common  understanding  of  the  HM  Practices. 
Provide  clarification  on  the  following: 

Process  models  and  process  modeling 

How  business  objectives  thread  to  high  maturity 

Common  causes  -  definition/concentration/expectations  at  ML5 

Defining  high  maturity  expectations  on  individual  PA  performance 

High  maturity  re-structuring  (including  stronger  alignment  of  ML4  &  ML5) 

Subprocess  -  selection/definition/level  of  instantiation 
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Establish  a  Clear  Understanding  Between 
Requirements  and  Expectations 


Problem  statement: 

Some  people  believe  that  the  role  of  the  informative  material  is  being 
exaggerated  in  appraisals. 

The  community  has  been  relying  on  presentations  and  published 
“audit  criteria”  to  better  understand  and  appraise  to  high  maturity. 

The  objective  in  a  nutshell: 

Document  high  maturity  requirements  in  high  maturity  process  area 
goals  and  high  maturity  expectations  in  high  maturity  process  area 
practices. 

Involves: 

Eliminate  the  need  for  appraisers  and  implementers  to  use  high 
maturity  presentations  or  audit  criteria  to  understand/  implement/ 
appraise  high  maturity. 
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High  Maturity  Restructuring 


The  restructuring  of  ML4  and  ML5  consists  of  the  following: 

•  OPP  &  QPM  constitutes  ML4. 

•  Create  a  new  process  area  called  Organization  Performance 
Management  (OPM). 

•  OPM,  CAR,  &  OID  constitutes  ML5. 

•  Revised  QPM  specific  practices  to  reflect  a  connection  between  CAR 
and  QPM. 
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PPBs,  QPPOs 
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Impact  on  Model  Size 
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Comparison  of  Models 


Measure 

CMMI  for  Development 

CMMI  for 
Acquisition 

CMMI  for  Services 

VI. 1 
Staged 

VI  .1 
Cont 

VI  .2 

VI  .3 
Draft* 

VI  .2 

VI  .3 
Draft* 

VI  .2 

VI  .3 
Draft* 

Pages 

715 

710 

560 

461 

428 

458 

531 

527 

Process 

Areas 

25 

25 

22 

22* 

22 

22* 

24 

24* 

Generic 

Goals 

2 

5 

5 

3* 

5 

3* 

5 

3* 

Generic 

Practices 

12 

17 

17 

13* 

17 

13* 

17 

13* 

Specific 

Goals 

55 

55 

50 

48* 

46 

46* 

52 

52* 

Specific 

Practices 

185 

189 

173 

165* 

161 

161* 

182 

179* 

*  High  maturity  changes  are  yet  to  be  finalized. 
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Version  1 .3  Appraisal  Updates 


Software  Engineering  Institute  CarnegieMellon 


CMMI  VI  .3 

February  23,  2010 

©2010  Carnegie  Mellon  University 


35 


Necessary  Changes  to  SCAMPI  for  VI. 3 


Provide  SCAMPI  support  for  each  constellation: 

•  Potential  terminology  barriers 

•  Scoping  considerations 

•  Identifying  appropriate  pre-requisites  for  team  members 

Correct  known  defects  and  issues: 

•  Errors  documented  during  the  use  of  vl  .2 

•  Common  pitfalls  encountered  based  on  user  feedback 

•  Areas  frequently  encountered  by  quality  assurance 
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Common  Themes  in  the  Change  Requests-, 


Scoping  Appraisals 

•  Confusion  caused  by  “focus-”  and  “non-focus”  projects 

•  Minimum  scoping  rules  for  a  wide  range  of  organization  types 

Collecting  Data 

•  Confusion  caused  by  “direct”  and  “indirect”  artifacts 

•  Handling  generic  practices 

Characterization  and  Rating 

•  Issues  with  characterization  rules 

•  Issues  with  rating  rules 
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Common  Themes  in  the  Change  Requests2 


Pain  Points  that  Make  SCAMPI  Difficult  to  Sustain 

•  Need  to  achieve  efficiency 

•  Expanding  organizational  scope 

•  True  cost  of  PI  IDs 

Attaining/Maintaining  Appraisal  Ratings 

•  Period  of  validity 

•  Maintenance  appraisals 

•  Delta  appraisals 

•  Enterprise  appraisals 
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Version  1.3  Training  Updates 
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Considerations  for  Training 


We  will  update  the  Introduction  to  CMMI  training  course  to  reflect  changes 
in  Version  1.3  models. 

Deploy  a  CMMI-SVC  three  day  course 

Create  a  “difference”  supplement  for  DEV 
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Transition... 


We  will  provide  an  on-line  upgrade  course  as  we  did  with  VI  .2. 

•  Users  make  the  transition  by  taking  the  upgrade  course. 

•  Instructors  and  Lead  Appraisers  make  the  transition  by  taking 
upgrade  course  and  passing  a  test. 

During  a  period  of  one  year,  organizations  may  use  either  VI  .2  or  VI  .3 
models  for  their  appraisals. 

All  appraisals  using  VI  .2  models  will  be  valid  for  3  years. 
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Summary 


There  are  four  drivers  for  Version  1 .3: 

1.  Clarify  high  maturity  practices 

2.  Simplify  generic  practices 

3.  Increase  appraisal  efficiency 

4.  Improve  commonality  across  the  constellations 

We  appreciate  the  input  you’ve  given  us  with  your  change  requests! 


-  Software  Engineering  Institute  CarnegieMellon 
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What  Have  We  Missed? 


Now  let’s  chat.... 
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